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SYSTEM FOR SIGNATURELESS 
TRANSMISSION AND RECEPTION OF DATA 
PACKETS BETWEEN COMPUTER 
NETWORKS 

5 

BACKGROUND OF THE INVENTION 

The present invention relates to the field of secure trans- 
mission of data packets, and in particular to a new system for 
automatically encrypting and decrypting data packets io 
between sites on the Internet or other networks of computer 
networks. 

It is becoming increasingly useful for businesses to trans- 
mit sensitive information via networks such as the Interact 
from one site to another, and concomitantly more urgent that 15 
such information be secured from uninvited eyes as it 
traverses the internetwork. At present, unsecured data is 
replicated at many sites in the process of being transmitted 
to a destination site, and trade secret or other private 
information, unless secured, is thereby made available to the 20 
public. 

It is possible for a user at the sending host to encrypt the 
data to be sent, and to inform the user who is to receive the 
data of the encryption mechanism used, along with the key 
necessary to decrypt. However, this requires communication 25 
and coordinated effort on the parts of both the sending and 
receiving users, and often the users will not take the requisite 
trouble and the packets will go unencrypted. 

Even when these packets are encrypted, the very fact of 3(J 
their being transmitted from user A to user B may be 
sensitive, and a system is needed that- will also make this 
information private. 

FIG. 1 illustrates a network of computer networks, includ- 
ing networks Nl, N2 and N3 interconnected via a public 35 
network 10 (such as the Internet). When network Nl is 
designed in conventional fashion, it includes several to 
many computers (hosts), such as host A and additional hosts 
20 and 30. Likewise, network N2 includes host B and 
additional hosts 40 and 50, while network N3 includes hosts 40 
60-90. There may be many hosts on each network, and 
many more individual networks than shown here. 

When a user at host A wishes to send a file, email or the 
like to host B, the file is split into packets, each of which 
typically has a structure such as packet 400 shown in FIG. 45 
7, including data 410 and a header 420. For sending over the 
Internet, the header 420 will be an internet protocol (IP) 
header containing the address of the recipient (destination) 
host B. In conventional fashion, each data packet is routed 
via the internetwork 10 to the receiving network N2, and 50 
ultimately to the receiving host B. 

As indicated above, even if the user at host A encrypts the 
file or data packets before sending, and user B is equipped 
with the necessary key to decrypt them, the identities of the 
sending and receiving hosts are easily discernible from the 55 
Internet Protocol (BP) addresses in the headers of the pack- 
ets. Current internetworks do not provide an architecture or 
method for keeping this information private. More basically, 
they do not even provide a system for automatic encryption 
and decryption of data packets sent from one host to another. 60 

SUMMARY OF THE INVENTION 

The system of the invention includes a tunnelling bridge 
positioned at the interface between a private network and a 65 
public network (or internetwork) for each of a number of 
such private networks. Each tunnelling bridge is a stand- 
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alone computer with a processor and a memory, and in each 
tunnelling bridge's memory is a hosts table identifying 
which hosts should have their data packets (sent or received) 
encrypted. Alternatively, a networks table could be used, 

5 indicating whether data packets to and from particular 
networks should be encrypted; or other predetermined cri- 
teria may be stored that indicate whether particular data 
packets should be encrypted. 
The tunnelling bridge for a given private network (or 

10 subnetwork of a private network) intercepts all packets sent 
outside the network, and automatically determines from the 
tables whether each such packet should be encrypted. If so, 
then the tunnelling bridge encrypts the packet using an 
encryption method and key appropriate for the destination 

15 host, adds an encapsulation header with source and desti- 
nation address information (either host address or IP broad- 
cast address for the network) and sends the packet out onto 
the internetwork. 
At the destination host, another tunnelling bridge inter- 

20 cepts all incoming data packets, inspects the source and 
destination address information, and determines from its 
local hosts (or networks) table whether the packet should be 
decrypted, and if so, by what method and using what key. 
The packet is decrypted, if necessary, and sent on to the 

25 destination host. 

In this way, all messages that are predetermined to require 
encryption, e.g. all messages from a given host A to another 
host B, are automatically encrypted, without any separate 

30 action on the part of the user. In this way, no one on the 
public internetwork can determine the contents of the pack- 
ets. If the encapsulation header utilizes the network IP 
source and destination addresses, with the source and des- 
tination host addresses encrypted, then the host identities are 

35 also concealed, and an intervening observer can discern only 
the networks* identities. 

The encapsulation header may include a field with an 
identifier of the source tunneling bridge. This is particularly 
useful if more than one tunnelling bridge is to be used for a 

40 given network (each tunnelling bridge having different 
encryption requirements and information), and in this case 
the receiving tunnelling bridge decrypts the data packets 
according to locally stored information indicating the 
encryption type and decryption key for all packets coming 
45 from the source tunnelling bridge. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a diagram of a network of computer networks in 
50 conjunction with which the system of the present invention 
may be used. 

FIG. 2 is a block diagram of a host computer A on 
computer network Nl shown in HG. 1 
FIG. 3 is a diagram of a network of computer networks 
55 incorporating tunnelling bridges according to the present 
invention. 

FIG. 4 is a block diagram of several tunnelling bridges of 
the present invention in a network of computer networks 
N1-N3 as shown in FIG. 3. 

FIG. 5 is a diagram of another configuration of networks 
incorporating tunnelling bridges according to the present 
invention. 

FIG. 6 is a flow chart illustrating the method of signa- 
65 tureless tunnelling of the present invention. 

FIG. 7 illustrates a conventional data structure for a data 
packet. 
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FIGS. 8-11 illustrate modified data structures for use in 
different embodiments of the system of the invention. 

FIG. 12 is a block diagram of a network of computer 
networks including two tunnelling bridges of the invention 
on a single computer network. 5 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

The system of the present invention is designed to be 10 
implemented in existing computer networks, and in the 
preferred embodiment uses the addition of a tunnelling 
bridge at junctions between local computer networks and 
public or large-scale networks such as the Internet, The 
mechanisms for carrying out the method of the invention are 15 
implemented by computers acting as these tunnelling 
bridges, incorporating program instrucdons stored in memo- 
ries of the tunnelling bridges and appropriate (standard) 
network connections and communications protocols. 

FIG. 3 shows a network 100 of networks Nl, N2 and N3 20 
according to the invention, where each network includes a 
tunneling bridge— TBI, TB2 andTB3, respectively— which 
intercepts all data packets from or to the respective net- 
works. Networks N1-N3 may in other respects be identical 
to networks N1-N3 in conventional designs. In the follow- 25 
ing description, any references to networks N1-N3 or hosts 
A and B should be taken as referring to the configuration 
shown in FIG. 3, unless specified otherwise. 

In this system, there are several modes of operation, 
numbered and discussed below as modes 1, 2, 2A, 3 and 3 A. 30 
Mode 1 uses the configuration of FIG. 1, while the other 
modes all use the configuration of FIG. 3. The features of the 
tunnelling bridges TBI and TB2 (including their program 
instructions, actions taken, etc.) in modes 2-3A are, in mode 
1, features of, respectively, hosts A and B. 35 

Each of the tunnelling bridges TB1-TB3 is preferably 
implemented in a separate, conventional computer having a 
processor and a memory, as shown in FIG. 4. The memory 
may be some combination of random-access-memory 4Q 
(RAM), read-only-memory (ROM), and other storage 
media, such as disk drives, CD-ROMs, etc. The program 
instructions for each of the bridges TB1-TB3 are stored in 
their respective memories, and are executed by their respec- 
tive microprocessors. The method of the present invention is 45 
carried out by a combination of steps executed as necessary 
by each of the processors of the sending host A, the 
tunnelling bridges TBI and TB2, and the receiving host B. 

Encryption of data is an important step in the overall 
method of the invention, but the particular encryption 50 
mechanism used is not critical. It is preferable to use a 
flexible, powerful encryption approach such as the DifBe- 
Hcllman method (see W. Difile and M. Hellman, "New 
Directions in Cryptography", IEEE Transactions of Infor- 
mation Theory, November 1976). (The use of encryption in 55 
connection with IP data transfers is discussed in some detail 
in applicant's copending patent application, "Method and 
Apparatus for Key-Management Scheme for Use With Inter- 
net Protocols at Site Firewalls" by A. Aziz, Ser. No. 08/258, 
344 filed Jun. 10, 1994, which application is incorporated $0 
herein by reference.) However, any encryption scheme that 
provides for encryption by a first machine, which sends the 
data packets, and decryption by a receiving machine, will be 
appropriate. 

FIG. 6 illustrates the method of the invention, and com- 65 
mences with the generation of data packets at the sending 
host A. The user at host A enters conventional commands for 
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transmitting a file or the like from host A to host B, and the 
host computer A carries out the standard procedures for 
breaking the file down into data packets as in FIG. 7, each 
including both the data 410 and a header 400. In the case of 
5 transmissions over the Internet, this will be the IP header. 
Though the current discussion will be directed in large part 
to P-specific implementations, it should be understood that 
any network protocol may be used in conjunction with the 
present invention. 

10 At box 200, the user at host A (see FIGS. 3 and 6) enters 
the conventional command for sending the file, email, or the 
like to a recipient, and host A generates data packets for 
sending over the Internet in the normal fashion. Each data 
packet initially has a structure like that of data packet 400 
shown in FIG. 7, including a data field 410 and a header field 
420. The header 420 includes the destination address, in this 
example the IP address of host B. 

The data packets are transmitted by host A at box 210, 
again in conventional fashion. However, at box 220, each 
packet is intercepted by the tunnelling bridge TBI (see 
FIGS. 3 and 4), when any of modes 2, 2A, 3 or 3A is used 
(see discussion below). When mode 1 (described below) is 
used, steps 220 and 280 are omitted, since this mode does 
not use tunnelling bridges; instead, the actions taken by the 
tunnelling bridges in modes 2-3A are all accomplished by 
the source and destination hosts themselves in mode 1. Thus, 
in the following discussion, wherever TBI or TB2 is men- 
tioned, it should be understood that in the case of mode 1, 
the same feature will be present in host A or host B, 
respectively. 

Stored in the memory of TBI (or host A, for mode 1) is 
a look-up table (not separately shown) of the addresses of 
hosts, both on the local network Nl and on remote networks 
such as N2 and N3, and an indication for each network 

35 whether data packets from or to that host should be 
encrypted. For instance, in this case the hosts table of TBI 
indicates that any messages sent from host A to host B 
should be encrypted. Thus, bridge TBI (or host A) looks up 
hosts A and B in its tables, and determines that the data 

40 packets to be transmitted must first be encrypted, as indi- 
cated at boxes 230 and 240 of FIG. 6. 

Alternatively, the table could stored the network identi- 
fiers (e.g. broadcast addresses) of networks Nl and N2, 
indicating that anything sent from network Nl to network 

45 N2 is to be encrypted. In this case, the table need not list 
each host in each network, which makes the table smaller 
and easier to maintain. 

If each host is listed, however, greater flexibility can be 
retained, since it may be that messages to or from particular 

so hosts need or should not be encrypted. In an alternative 
embodiment, the look-up table lists the networks Nl and N2 
as networks to and from which packets should be encrypted, 
and also includes a hosts section of the table indicating 
exceptions to the normal encryption rule for these networks. 

55 Thus, if networks Nl and N2 are listed in the look-up table, 
then packets travelling from Nl to N2 should normally be 
encrypted; however, if there is an "exceptions" subtable 
indicating that no packets from host A are to be encrypted, 
then the normal rule is superseded. The exceptions can, of 

60 course, go both ways: where the normal rule is that the 
packets for a given network pair should/should not be 
encrypted, and the exception is that for this given host 
(source or recipient) or host pair, the packet should not/ 
should nonetheless be encrypted. In this embodiment, the 

65 small size and ease of maintenance of the network tables is 
by and large retained, while the flexibility of the hosts table 
is achieved. 
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If the data to be transmitted from host A to host B (or 
network Nl to network N2) should not be encrypted, then 
the method proceeds directly to step 270, and the packet in 
question is transmitted unencrypted to the destination, via 
the Internet (or other intervening network). 5 

In this example, the packets are encrypted at box 250. 
This is carded out by the tunnelling bridge TBI, according 
to whichever predetermined encryption scheme was 
selected, the primary requirement being that of ensuring that 
TB2 is provided with the same encryption scheme so that it 10 
can decrypt the data packets, TB2 must also be provided in 
advance with the appropriate key or keys for decryption. 

The Encapsulation Header l5 

At box 260, an encapsulation header is appended to the 
encrypted data packet. This header can take one of several 
alternative forms, according to the requirements of the user. 
Several modes of packet modification can be accommodated 
using the same basic data structure (but with differences in 20 
the information that is appended in the encapsulation 
header), such as the following: 



Mode Appended information 



1 Encryption key management information (itself 
unencrypted) New IP header including originally 
generated IP addresses of source and destination 
hosts (unencrypted) 

2 Encryption key management information (in encrypted _ n 
form) Tunnelling bridge identifier for sender 

(unencrypted) New IP header including broadcast 
addresses of source and destination networks 
(unencrypted) 

2A (Same as mode 2, but without the tunnelling bridge 
identifier.) 

3 Encryption key management information (encrypted) 35 
Optional: tunnelling bridge identifier for sender 

(unencrypted) New IP header including originally 
generated IP addresses of source and destination 
hosts (unencrypted) 
3A (Same as mode 3, but without the tunnelling 

bridge identifier.) t 40 



Data structures for modes 1, 2 and 3 are depicted in FIGS. 
8, 9 and 10, respectively, wherein like reference numerals 
indicate similar features, as described below. The data 
structure for mode 2A is illustrated in FIG. 11, and mode 3A 45 
may use the data structure of FIG. 8. 

The data structure 402 for mode 1 is represented in FIG. 
8. The original data 410 and original header 420 are now 
encrypted, indicated as (410) and (420). Encryption key 5Q 
management information 440 is appended (in encrypted 
form) as pan of the new encapsulation header 430, along 
with a new IP header 450, including the addresses of the 
source and destination hosts. The information 430 includes 
indicates which encryption scheme was used. 55 

Key management information can include a variety of 
data, depending upon the key management and encryption 
schemes used. For instance, it would be appropriate to use 
applicant's Simple Key-Management for Internet Protocols 
(SKIP), which is described in detail in the attached Appen- $q 
dix A. 

In FIGS. 7-11, the fields with reference numerals in 
parentheses are encrypted, and the other fields are unen- 
crypted. Thus, in FIG. 8, the original data field 410 and 
address field 420 are encrypted, while the new encapsulation 65 
header 430, including the key management information 440 
and the IP header 450, is not encrypted. 
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In this embodiment, the tunnelling bridges TBI and TB2 
might not be used at all, but rather the hosts A and B could 
include all the instructions, tables, etc. necessary to encrypt, 
decrypt, and determine which packets are to be encrypted 

5 and using which encryption scheme. Mode 1 allows any 
intervening observer to identify the source and destination 
hosts, and thus does not provide the highest level of security. 
It does, however, provide efficient and automatic encryption 
and decryption for data packets between hosts A and B, 

10 without the need for additional computers to serve as TBI 
and TB2. 

Alternatively, in mode 1 field 440 could include the IP 
broadcast addresses of the source and destination networks 
(instead of that of the hosts themselves), and in addition may 

15 include a code in the encryption key management informa- 
tion indicating which encryption scheme was used. This 
information would then be used by an intercepting computer 
(such as a tunnelling bridge) on the destination network, 
which decrypts the data packet and sends it on to the 

20 destination host. 

In mode 2, a data structure 404 is used, and includes a new 
encapsulation header 432, It includes key encryption man- 
agement information 440, which is appended to the original 
data packet 400, and both are encrypted, resulting in 

25 encrypted fields (410), (420) and (440) shown in FIG. 9. A 
new IP header 470 including the broadcast addresses of the 
source and destination networks (not the addresses of the 
hosts, as in field 450 in FIG. 8) is appended. In addition, a 
tunnelling bridge identifier field 460 is appended as part of 

30 the encapsulation header 432. Here, fields 410, 420 and 440 
in this embodiment are all encrypted, while fields 460 and 
470 are not. 

The tunnelling bridge identifier identifies the source tun- 
nelling bridge, i.e. the tunnelling bridge at the network 

35 containing the host from which the packet was sent The 
recipient tunnelling bridge contains a tunnelling bridge 
look-up table, indicating for each known tunnelling bridge 
any necessary information for decryption, most notably the 
decryption method and key. 

40 An appropriate tunnelling bridge identifier might be a 
three-byte field, giving 224 or over 16 million unique 
tunnelling bridge identifiers. An arbitrarily large number of 
individual tunnelling bridges may each be given a unique 
identifier in this way, simply by making the field as large as 

45 necessary, and indeed the field may be of a user-selected 
arbitrarily variable size; If desired, a four-byte field can be 
used, which will accommodate over 4 billion tunnelling 
bridges, far exceeding present needs. 

50 Using mode 2, any observer along the circuit taken by a 
given data packet can discern only the tunnelling bridge 
identifier and the IP broadcast addresses for the source and 
destinationnetworks. 
The IP broadcast address for the destination network will 

55 typically be something like " 1 29. 144.0.0". which represents 
a particular network (in this case, <( Eng;Sun.COM") but not 
any specific host Thus, at intermediate points on the route 
of the packet, it can be discerned that a message is traveling 
from, say, "washington.edu" to "Eng.Sun.COM", and the 

50 identification number of the receiving tunnelling bridge can 
be detennihed, but that is the extent of it; the source and 
destination hosts, the key management information, and the 
contents of the data packet are all hidden. 
Mode 2A uses the data structure shown in FIG. 11, 

65 wherein the IP broadcast addresses for the source and 
recipient networks Nl and N2 are included in the encapsu- 
lation header field 470, but no tunnelling bridge identifier is 
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used. This embodiment is particularly suitable for networks 
where there is only one tunnelling bridge for the entire 
network, or indeed for several networks, as illustrated in 
FIG. 5. 

In FIG. 5, a packet sent from host C to host D will first be 5 
sent from network N4 to network N5, and will Ihen be 
intercepted by the tunnelling bridge TB4 T which intercepts 
all messages entering or leaving these two networks. TB4 
will encrypt the packet or not, as indicated by its hosts 
look-tip table. The packet traverses the public network and 10 
is routed to network N7, first being intercepted by tunnelling 
bridge TB5 (which intercepts all messages entering or 
leaving networks N6-N8), and at that point being decrypted 
if necessary. 

In this embodiment or any embodiment where a packet is 15 
sent from a host on a network where a single tunnelling 
bridge is used for the entire source network or for multiple 
networks which include the source network, a tunnelling 
bridge identifier is not a necessary field in the encapsulation 
header. Since in this case only a given tunnelling bridge 
could have intercepted packets from a given host (e.g., TB4 
for host C in FIG. 5), the identity of the source tunnelling 
bridge is unambiguous, and the destination tunnelling bridge 
TBS will include a table of hosts and/or networks cross- 
correlated with TB4. Having determined that tunnelling 
bridge TB4 was the source tunnelling bridge, TBS then 25 
proceeds with the correct decryption. 

This approach has certain advantages, namely that it 
eliminates the need to "name" or number tunnelling bridges, 
and reduces the sizes of the data packets by eliminating a 
field. However, a tunnelling bridge identifier field provides 30 
flexibility. For instance, in FIG. 12, subnetworks Nil and 
N12 are part of one larger network N10, and each subnet- 
work Nil and N12 has its own assigned tunnelling bridge 
(TB7 and TB8, respectively). Thus, subnetworks Nil and 
N12 can be subjected to different types of encryption, 35 
automatically, and that encryption can be altered at will for 
one subnetwork, without altering it for the other. 

A packet traveling from host F to host E in FIG, 12 will 
include a source tunnelling bridge identifier (TB7) so that, 
when it reaches TB6 at network N9, it is identified correctly 40 
as having been encrypted by TB7 and not TB8. In this way, 
tunnelling bridge TB6 need maintain a table only the infor- 
mation pertaining to the tunnelling bridges, and does not 
need to maintain encryption/decryption specifics for the host 
or network level. (Note that TB6 still maintains information 45 
relating to whether to encrypt messages sent between host A 
and host B or network Nl and network N2, as the case may 
be, as discussed above.) 

The tunnelling bridge identifier may be used for a variety ^ 
of other purposes relating to the source tunnelling bridge, 
such as statistics recording the number of packets received 
from that tunnelling bridge, their dates and times of trans- 
mission, sizes of packets, etc. 

An alternative to the use of hosts or networks tables in the 55 
memories of the source and destination tunnelling bridges 
(or source and destination hosts, as the case may be) would 
be any information identifying one or more predetermined 
criteria by which the source host or source tunnelling bridge 
determines whether to encrypt a given data packet. Such go 
criteria need not merely be source and destination informa- 
tion, but could include packet contents, time of transmission, 
subject header information, user id., presence of a key word 
(such as "encrypt") in the body of the packet, or other 
criteria, 65 

Mode 3 uses a data structure 406 as shown in FIG. 10, 
which is identical to the data structure 402 except for the 
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addition of field 46*0 containing the tunnelling bridge iden- 
tifier, which is the same as the tunnelling bridge identifier 
discussed above relative it mode 2. 
In this embodiment, as in mode 1, field 450 includes the 

5 original host IP addresses for the source and destination 
hosts (not the addresses of the networks, as in mode 2), and 
thus an observer of a mode 3 packet will be able to determine 
both the original sender of the data packet and the intended 
receiver. Either mode contains sufficient information to 

10 route packets through an internet to a recipient network's 
tunnelling bridge for decryption and ultimate delivery to the 
recipient host. 

Mode 3A may use the data structure shown in FIG. 8, in 
conjunction with a network configuration such as those 
15 shown in FIGS. 3 or 12. The mechanisms and relative 
advantages are identical to those described above for mode 
2A, while the structure reveals the source and destination 
host addresses. 

20 Whichever encapsulation header is added at box 260 (see 
FIG. 6), the packet is, at box 270, then transmitted to the 
destination network. At box 280, the destination network's 
tunnelling bridge (here, TB2 shown in FIG. 3) intercepts the 
packet, which is accomplished by an instruction routine by 

25 which all packets are intercepted and- inspected for encap- 
sulation header information indicating encryption. 

Thus, at box 290, the encapsulation header of the -packet 
is read, and at box 300 it is determined whether the packet 
was encrypted. If a tunnelling bridge identifier forms a part 

30 of the encapsulated packet, then the method of encryption 
and decryption key are determined from the destination 
tunnelling bridge's (or destination host's, in the case of 
mode 1) local tables. 
If no encryption was carried out on the packet, then it is 

35 sent on without further action to the correct host, as indi- 
cated at box 340. Otherwise, its encryption method is 
determined (box 320), and the packet is decrypted accord- 
ingly (box 330), and then sent on as in box 340. 

40 APPENDIX A 



Simple Key-Management For Internet Protocols 
(SKIP) Abstract 

A5 

There are occasions where it is advantageous to put 
authenticity and privacy features at the network layer. The 
vast majority of the privacy and authentication protocols in 
the literature deal with session oriented key-management 

50 schemes. However, many of the commonly used network 
layer protocols (e.g IP and IPng) are session-less datagram 
oriented protocols. We describe a key -management scheme 
that is particularly well suited for use in conjunction with a 
session-less datagram protocol like IP or IPng. We also 

55 describe how this protocol may be used in the context of 
Internet multicasting protocols. This key-management 
scheme is designed to be plugged into the IP Security 
Protocol (IPSP) or IPng. 

1.0 Overview 

Any kind of scalable and robust key-management scheme 
that needs to scale to the number of nodes possible in the 
Internet needs to be based on an underlying public-key 
65 certificate based infrastructure. This is the direction that, e.g, 
the key-management scheme for secure Internet, e-mail, 
Privacy Enhanced Mail or PEM [1], is taking. 
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The certificates used by PEM are RSA public key certifi- 
cates. Use of RSA public key certificates also enable the 
establishment of an authenticated session key [2,3], (By an 
RSA public key certificate, what is meant here is that the key 
being certified is an RSA public key.) 5 

One way to obtain authenticity and privacy at a datagram 
layer like IP is to use RSA public key certificates. (In the 
following description we use the term IP, although IP is 
replacable by IPng in this context). 

There are two ways RSA certificates can be used to 10 
provide authenticity and privacy for a datagram protocol. 
The first way is to use out-of-band establishment of an 
authenticated session key, using one of several session key 
establishment protocols. This session key can then be used 
to encrypt IP data traffic. Such a scheme has the disadvan- 15 
tage of establishing and maintaining a pseudo session state 
underneath a session-less protocol. The IP source would 
need to first communicate with the IP destination in order to 
acquire this session key. 

Also, as and when the session key needs to be changed, 20 
the IP source and the 3P destination need to communicate 
again in order to make this happen. Each such communica- 
tion involves the use of a computationally expensive public- 
key operation. 

The'second way an RSA certificate can be used is to do 25 
in-band signalling of the packet encryption key, where the 
packet encryption key is encrypted in the recipient's public 
key. This is the way, e.g, PEM and other public-key based 
secure e-mail systems do message encryption. Although this 
avoids the session state establishment requirement, and also 30 
does not require the two parties to communicate in order to 
set up and change packet encryption keys, this scheme has 
the disadvantage of having to carry the packet encryption 
key encrypted in the recipient's public key in every packet 

Since an RSA encrypted key would minimally need to be 35 
64 bytes, and can be 128 bytes, this scheme incurs the 
overhead of 64-128 bytes of keying information in every 
packet (As time progresses, the RSA block size would need 
to be closer to 128 bytes simply for security reasons.) Also, 
as and when the packet encryption key changes, a public key 40 
operation would need to be performed in order to recover the 
new packet encryption key. Thus both the protocol and 
computational overhead of such a scheme is high. 

Use of certified Diffie-Hellman (DH) [4] public-keys can 
avoid the pseudo session state establishment and the com- 
munications requirement between the two ends in order to 
acquire and change packet encrypting keys. Furthermore, 
this scheme does not incur the overhead of carrying 64-128 
bytes of keying information in every packet. 

This kind of key -management scheme is better suited to 
protocols like IP, because it doesn't even require the remote 
side to be up in order to establish and change packet 
encryption keys. This scheme is described in more detail 
below. 55 

2.0 Simple Key-Management for Internet Protocols 
(SKIP) 

We stipulate that each IP based source and destination has 
a certified Diffie-Hellman public key. This public-key is ^ 
distributed in the form of a certificate. The certificate can be 
signed using either an RSA or DSA signature algorithm. 
How the certificates are managed is described in more detail 
later. 

Thus each IP source or destination I has a secret value i, €5 
and a public value g**i mod p. Similarly, IP node J has a 
secret value j and a public value g**j mod p. 
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Each pair of IP source and destination I and J can acquire 
a shared secret g**ij mod p. They can acquire this shared 
secret without actually having to communicate, as long as 
the certificate of each IP node is known to all the other IP 
5 nodes. Since the public-key is obtained from a certificate, 
one natural way for all parties to discover the relevant 
public-keys is to distribute these certificates using a direc- 
tory service. 

10 This computable shared secret is used as the basis for a 
key-encrypting-key to provide for IP packet based authen- 
tication and encryption. Thus we call g**ij mod p the 
long-term secret, and derive from it a key Kij. Kij is used as 
the key for a shared-key cryptosystem (SKCS) like DES or 

15 RC2. 

Kij is derived from g**ij mod p by taking the high order 
key-size bits of g**ij mod p. Since g**ij mod p is minimally 
going to be 512 bits and for greater security is going to be 

20 1 024 bits or higher, we can always derive enough bits for use 
as Kij which is a key for a SKCS. SKCS key sizes are 
typically in the range of 40-256 bits. 

An important point here is that Kij is an implicit pair- wise 

25 shared key. It does not need to be sent in every packet or 
negotiated out-of-band. Simply by examining the source of 
*an IP packet, the destination IP node can compute this shared 
key Kij. Because this key is implicit, and is used as a master 
key, its length can be made as long as desired, without any 

30 additional protocol overhead, in order to make cryptanalysis 
of Kij arbitrarily difficult. 

We use Kij to encrypt a transient key, which we call Kp 
(for packet key). Kp is then used to encrypt/authenticate an 

35 IP packet or collection of packets. This is done in order to 
limit the actual amount of data in the long-term key. Since 
we would like to keep the long-term key for a relatively long 
period of time, say one or two years, we don't encrypt the 
actual IP data traffic in key Kij. 

40 Instead we only encrypt transient keys in this long-term 
key, and use the transient keys to encrypt/authenticate IP 
data traffic. This limits the amount of data encrypted in the 
long-term key to a relatively small amount even over a long 
period of time like, say, one year. 

45 Thus the first time an IP source I, which has a secret value 
i, needs to communicate with IP destination J, which has a 
secret value j, it computes the shared secret g**ij mod p. It 
can then derive from this shared secret the long-term key 

50 Kij. IP source I then generates a random key Kp and 
encrypts this key using Kij. It encrypts the relevant portion 
of the IP packet in key Kp (which may be the entire IP packet 
or just the payload of the TP packet depending on the 
next-protocol field in IPSP protected data potion). 

55 The value of the SAID field is used by SKIP to indicate 
the mode of processing and to identify the implicit inter- 
change key. Typical modes of processing are encrypted, 
encrypted-authenticated, authenticated, compression etc. 

The modes of operation are identified by the upper 6 bits 
of the SAID field. The meanings of these upper 6 bits is 
specified in section 2.5 below on SAID derived processing 
modes. The low 22 bits of the SAID field are zero. 
If the next protocol field is 3P, (in other words IPSP is 

65 operating in encrypted-encapsulated mode), the packet looks 
as follows. It sends the encrypted IP packet, the encrypted 
key Kp, encapsulated in a clear outer IP Header. 
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Clear IP Header / 
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Vcr. I SAID I Beginning of IPSP header 
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1 

Kp encrypted in Kij / (typically 8-16 bytes) 

1 
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I 

Message Indicator (eg IV) / (typically 8 bytes) j 5 

I 



I 

Protected IPSP Payload / 
/ 
I 



20 



35 



40 



In order to prepare this packet for emission on the 
outbound side of IP node I, no communication was neces- 
sary with IP node J. 25 

When IP node J receives this packet, it also computes the 
shared secret Kij and caches it for later use. (In order to do 
this, if it didn't already possess I's certificate, it may have 
obtained this from the local directory service.) Using Kij it 
obtains Kp, and using Kp it obtains the original IP packet, 30 
which it then delivers to the appropriate place which is either 
a local transport entity or another outbound interface. 

The Message Indicator (MI) is a field that is needed to 
preserve the statelessness of the protocol. If a single key is 
used in order to encrypt multiple packets, (which is highly 
desirable since changing the key on a per packet basis 
constitutes too much overhead) then the packets need to be 
decryptabie regardless of lost or out-of-order packets. The 
message indicator field serves this purpose. 

The actual content of the MI field is dependent on the 
choice of SKCS used for Kp and its operating mode. If Kp 
refers to a block cipher (e.g., DES) operating in Cipher- 
Block-Chaining (CBC) mode, then the MI for the first 
packet encrypted in key Kp is the Initialization Vector (IV). 45 
For subsequent packets, the MI is the last blocksize-bits of 
ciphertext of the last (in transmit order) packet. For DES or 
RC2 this would be last 64 bits of the last packet. For stream 
ciphers like RC4, the MI is simply the count of bytes that 
have already been encrypted in key Kp (and can be 64 bits 5Q 
long also). 

If the source IP node (I in this case) decides to change the 
packet encryption key Kp, the receiving IP node J can 
discover this fact without having to perform a public-key 
operation. It uses the cached value Kij to decrypt the 55 
encrypted packet key Kp, and this is a shared-key crypto- 
system operation. Thus, without requiting communication 
between transmitting and receiving ends, and without neces- 
sitating the use of a public-key operation, the packet 
encrypting key can be changed by the transmitting side. ^ 

Since the public keys in the certificates are DH public 
keys, the nodes themselves have no public-key signature 
algorithm. This is not a major problem, since signing on a 
per-packet basis using a public-key cryptosystem is too 
cumbersome in any case. The integrity of the packets is 65 
determined in a pairwise fasion using a symmetric crypto- 
system. 
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2.1 SKIP for Packet Authentication 

In order to achieve authentication in the absence of 
privacy, SKIP compliant implementations use the encrypted 

5 packet key Kp to encrypt a message-digest of the packet, 
instead of the packet itself. This encrypted digest is 
appended at the end of the data portion of the IPSP. As 
before, Kij alg and Kp alg identify the two encryption 
algorithms for keys Kij and Kp, MD alg is a 1 byte identifier 

10 for the message digest algorithm. 

This mode of operation is indicated by the SAID value 
which is further specified in Section 2.x. 



0 12 3 

I 



20 



/ Clear IP Header 


1 
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IP protocol s= IPSP 


1 Ver. i SAID 
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Beginning of IPSP header 


1 Kij alg 1 Kp alg I MD alg 1 Rsvd 
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(1 by te for each algorithm ID) 


/ Kp encrypted in Kij 


( 
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(typically 8-16 bytes) 


/ Protected IPSP Payload 


! 
/ 
/ 
1 




/ Message Digest encrypted in Kp 


1 
/ 
J 


(typically 8-16 bytes) 



2.2 Intruder in the Middle Attacks 

Unauthenticated Diffie-Hellman is susceptible to an 
intruder in the middle attack. To overcome this, authenti- 
cated Diffie-Hellman schemes have been proposed, that 
40 include a signature operation with the parties private signa- 
ture keys. 

SKIP is not susceptible to intruder in the middle types of 
attacks. This is because the Diffie-Hellman public param- 

45 eters are long-term and certified. Intruder in the middle 
attacks on Diffie-Hellman assume that the parties cannot 
determine who the public Diffie-Hellman keys belong to. 
Certified Diffie-Hellman public keys eliminate this possibil- 
ity, without requiting any exchange of messages between the 

50 two parties or incurring the computational overhead of large 
exponent exponentiations (e.g., RSA signatures). 

2.3 Storage of Cached Keys 

55 Since the Kij values need to be cached for efficiency, 
reasonable safeguards need to be taken to protect these keys. 

One possible way to do this is to provide a hardware 
device to compute, store and perform operations using these 
^ keys. This device can ensure that there are no interfaces to 
extract the key from the device. 

2.4 Manual Keying 

As an interim measure, in the absence of certification 
65 hierarchies, nodes may wish to employ manually exchanged 
keying information. To handle such cases, the pair key Kij 
can be the key that is manually set up. 
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Since manual re-keying is a slow and awkward process, 
it still makes sense to use the two level keying structure, and 
encrypt the packets has the same benefit as before, namely 
it avoids over-exposing the pair key which is advantageous 
to maintain over relatively long periods of time. This is 5 
particularly true for high-speed network links, where it is 
easy to encrypt large amounts of data over a short period of 
time. 

2.5 Processing Modes and SAID Values io 

The upper 6 bits of the SAID field are used to indicate the 
processing mode. The processing modes defined so far are, 
encryption, authentication, compression, and packet 
sequencing (for playback protection). Since none of these J5 
modes is mutually exclusive, multiple bits being on indicate 
the employment of all the relevant processing modes. 

SAID bits 

Bit 22 Bit 23 Bit 24 Bit 25 Bit 26 Bit 27 

+ 

I Encrypted I Authenticated I Compressed I Sequenced I Rsvd I Rsvd 



25 

Bit 22=1 if packet is encrypted, Bit 22=0 otherwise 
Bit 23=1 if packet is authenticated, Bit 23=0 otherwise 
Bit 24=1 if packet is compressed before encryption, Bit 

24=0 otherwise, 30 
Bit 25=1 if packets are sequenced, Bit 25=0 otherwise 
Bits 26 and 27 are reserved for future use, and shall be 0 

until specified, 35 
For example, to indicate that a packet is encrypted and 
authenticated, Bits 22 and 23 shall be one. 



3.0 SKIP for Multicast IP * 

It is possible to use this kind of scheme in conjunction 
with datagram multicasting protocols like IP (or IPng) 
multicast [5]. This requires key-management awareness in 45 
the establishment and joining process of multicast groups. 

In order to distribute multicast keying material, the notion 
of a group owner needs to exist When secure multicasting 
to multicast address M is required, a group membership 50 
creation primitive will need to establish the group secret 
value Km and the membership list of addresses that are 
allowed to transmit and receive encrypted multicast data- 
grams to and from group address M. 55 

The group key Km is not used as a packet encryption key, 
but rather as the group Interchange Key (IK). 

Nodes wishing to transmit/receive encrypted datagrams to 
multicast address M need to acquire the group IK Km, This ^ 
is done by sending an encrypted/authenticated request to 
join primitive to the group owner. If the requesting node's 
address is part of the group's membership, then the group 
owner will send the IK Km, and associated lifetime infor- ^ 
mation in an encrypted packet, using the pairwise secure 
protocol described in Section 2 above. 



5,548,646 

14 

Transmitting nodes to group address M will randomly 
generate packet encryption keys Kp, and encrypt these keys 
using Km. The packet structure is similar to the structure 
5 used for encrypted unicast IPSP packets, except for the fact 
that the packet keys Kp are not encrypted in the pair-wise 
keys Kij, but instead are encrypted using the group IK Km. 
An example encrypted multicast packet is shown below. 
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Clear IP Header 



Ver. E SAID 

Kp alg I 3 bytes Rsvd 



Kp encrypted in Km 



Message Indicator (e.g. IV) 



Protected IPSP Payload 



IP protocol = IPSP 
Beginning of IPSP header 

(typically 8-16 bytes) 
(typically 8 bytes) 



There are two distinct advantages of this scheme. First, 
every member of the multicast group can change packet 
encryption keys as often as it desires, without involving 
key-setup communications overhead involving every mem- 
ber of the group. 

Second, since all the packet encryption keys are different, 
there is no, problem in using stream-ciphers with multicast. 
This is because each source of encrypted traffic uses a 
different key-stream and thus there is no key-stream reuse 
problem. If all members of the multicast group used the 
same packet encryption key (as e.g stipulated in the current 
draft of 802.10 key-management), then key-seeded stream 
ciphers could not be used with multicast. 

How' the identity of the group owner is established and 
communicated to the participating nodes is left to the 
application layer. However, this also needs to be done in a 
secure fashion, otherwise the underlying key-management 
facility can be defeated. 
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4.0 Management of DH Certificates 

Since the nodes* public DH values are communicated in 
the form of certificates, the same sort of multi-tier certifi- 
cation structure that is being deployed for PEM [6] and also 
by the European PASSWORD project can be used. Namely, 5 
there can be a Top Level Certifying Authority (TLCA) 
which may well be the same the Internet Policy Registration 
Authority (IPRA), Policy Certifying Authorities (PCAs) at 
the second tier and organizational CAs below that 

In addition to the identity certificates, which are what are 10 
part of PEM certificate infrastructure, we also need addi- 
tional authorization certificates, in order to properly track the 
ownership of IP addresses. Since we would like to directly 
use IP addresses in the DH certificates, we cannot use name 
subordination principles alone (as e.g used by PEM) in order 15 
to determine if a particular CA has the authority to bind a 
particular IP address to a DH public value. 

We can still use the X.509/PEM certificate format, since 
the subject Distinguished Name (DN) in the certificate can 
be the numeric string representation of a list of IP addresses. 20 

Since the nodes only have DH public keys, which have no 
signature capability, the nodes are themselves unable to 
issue certificates. This means that there is an algorithmic 
termination of a certificate path in a leaf node, unlike the 
certificate hierarchy employed in, e,g PEM, where every leaf 25 
node is potentially a rogue CA. 

The node certificates are issued by organizational CAs 
which have jurisdiction over the range of IP addresses that 
are being certified. The PCAs will have to perform suitable 
checks (in line with the advertised policy of that PCA) to 30 
confirm that the organization which has jurisdiction over a 
range of addresses is issued a certificate giving it the 
authority to certify the DH values of individual nodes with 
those addresses. This authority will be delegated in the form 
of a authorization certificate signed by the PCA. For the 35 
purposes of authorization, the CA's Distinguished Name 
(DN) will be bound to the range of IP addresses over which 
it has jurisdiction. The CA has either an RSA or DSA 
certificate issued by the PCA. 

An authorization certificate will also contain information ^ 
about whether the CA to whom authority is being delegated 
can sub-delegate that authority. The CA which has delegat- 
able authority over a range of IP addresses can delegate 
authority over part of the range to a subordinate CA, by 
signing another authorization certificate using its own pri- 
vate key. If the authority is non-delegatable, then the CA 45 
cannot delegate authority for that range of addresses. 

The range of IP addresses are identified in the authoriza- 
tion certificate in the form of a list of IP address prefix, 
length pairs. 

50 

5.0 X.509 Encoding of SKIP DH Certificates 

5.1 Encoding of DH Public Values 

The encoding of a DH Public value in an X.509 certificate 55 
will be in the form of an INTEGER. The algorithm inden- 
tificr will be as defined in PKCS #3 [7], Thus 

DHPublicKey : :=INTJEGER 
and from PKCS #3, 60 



Algorithmldentificr ::= 
SEQUENCE { 

algorithm OBJECT IDENTIFIER 
SEQUENCE { 

prime INTEGER, ~- p 
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-continued 



base INTEGER, — g 

privateValueLenglh INTEGER OPTIONAL 

} 

5 } 



with the OBJECT IDENTIFIER value being 



dhKcyAgreement OBJECT IDENTIFIER ::= 
{iso{l) member-body(2) US(840) 
isadsi(H3549) plccs(l) 3 1} 



which is also taken from PKCS #3. 
DHPublicKey is what gets encapsulated as the BIT 
15 STRING in SubjectPublicKeylnfo of an X.509 certificate in 
the obvious manner. 

5.2 Encoding of the Distinguished Name (DN) 

20 The certificate is allowed to bind multiple IP addresses to 
a single public value to accommodate cases where a single 
IP node has multiple IP addresses. The SEQUENCE OF 
construct in a DN readily allows for this. What is needed is 
an OBJECT IDENTIFIER for an AttributeType specifying 

25 an IP address. This is defined here as, 



ipAddrcss ATTRIBUTE WITH ATTRIBUTE-SYNTAX 
PrinlablcSlring (SlZE(i.:cb-ip Address)) 
{ipsec-oid 1 } - Need to register this XXX 
30 The DN in the certificate can contain multiple 



of these by iterating on the SEQUENCE OF construct of the 
Relative Distinguished Name Sequence. 
The Printable string contains either the hexadecimal rep- 
35 resentation or standard dot notation representation of an IP 
address. 

5.3 Encoding of an Authorization Certificate 

40 An authorization certificate is associated with each CA 
below the PCA level. The authorization certificate in effect 
entitles a CA to bind IP addresses to DH public keys. 

6.0 Conclusions 

45 

We have described a scheme, Simple Key-Management 
for Internet Protocols (SKIP) that is particularly well suited 
to connectionless datagram protocols like IP and its replace- 
ment candidate SIPP. Both the protocol and computational 

50 overheads of this scheme are relatively low. In-band sig- 
nalled keys incur the length overhead of the block size of a 
shared-key cipher. Also, setting and changing packet 
encrypting keys involves only a shared-key cipher opera- 
tion. Yet the scheme has the scalability and robustness of a 

55 public-key certificate based infrastructure. 

A major advantage of this scheme is that establishing and 
changing packet encrypting keys requires no communica- 
tion between sending and receiving nodes and no establish- 
ment of a pseudo-session state between the two sides is 

60 required. 

In many ways the key-management scheme here has 
structural similarittes with the scheme used by PEM [1]. 
Both use the concept of an inter-change key (in our case that 
is the pair keys Kij) and data encrypting keys (the packet 
65 encryption keys Kp). By using the implicit shared secret 
property of long-term DH public values, and treadng the 
resulting keys as keys for a SKCS, we have reduced the 
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protocol overhead substantially as compared to the 
overhead of PEM when used in conjunction with an 
asymmetric key-management system. 

We have also described how this scheme may be 
5 used in conjunction with datagram multicast protocols, 

allowing a single encrypted datagram to be multicast to all 
the receiving codes. 
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What is claimed: 

30 

1 . A method for transmitting and 

receiving packets of data via a internetwork for a first host 
computer on a first computer network to a second host 
computer on a second computer network, the first and 
3 5 second computer networks including, respectively, first and 

second bridge computers, each of said first and second host 
computers and first and second bridge computers including 
a processor and a memory for storing instructions for 
execution by the processor, each of said first and second 
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bridge computers further including memory for storing at 
least one predetermined encryption/decryption mechanism 
and information identifying a predetermined plurality of 
host computers as hosts requiring security for packets 
5 transmitted between them, the method being carried 

[carded] out be means of the instructions stored on said 
respective memories and including the steps of: 

(1 ) generating, by the first host computer, a first data 
packet for transmission to the second host computer, a 

1 0 portion of the data packet including information 

representing an internetwork address of the first host 
computer and internetwork address of the second host 
computer; 

(2) in the first bridge computer, intercepting the first 
1 5 data packet and determining whether the first and second 

host computers are among the predetermined plurality of 
host computers for which security is required, and if not, 
proceeding to step 5, and if so, proceeding to step 3; 

(3) encrypting the first data packet in the first bridge 
20 computer; 

(4) in the first bridge computer, generating and 
appending to the first data packet an encapsulation header, 
including: 

(a) key management information identifying the 
25 predetermined encryption method, and 

(b) a new address header representing the source and 
destination for the data packet, hereby generating a 
modified data packet; 

(5) transmitting the data packet from the first bridge 
3 0 computer via the internetwork to the second computer 

network; 

(6) intercepting the data packet at the second bridge 
computer; 

(7) in the second bridge computer, reading the 

3 5 encapsulation header, and determining therefrom whether 

the data packet was encrypted, and if not, proceeding to 
step 10, and if so, proceeding to step 8; 
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(8) in the second bridge computer, determining 
which encryption mechanism was used to encrypt the first 
data packet; 

(9) decrypting the first data packet by the second 
bridge computer; 

( 1 0) transmitting the first data packet from the second 
bridge computer to the second host computer, and 

(11) receiving the unencrypted data packet at the 
second host computer. 

2. The method of claim 1, wherein the 

new address header for the modified data packet includes 
the address of the second bridge computer. 



15 3 . The method of claim 2, wherein the 

new address header for the modified data packet includes 
an identifier of the second bridge computer. 

4. The method of claim 1 , wherein the 
20 new address header of the modified data packet includes 

the address of the second host computer. 

5 . The method of claim 4, wherein the 
new address header for the modified data packet includes 

25 an identifier of the second bridge computer. 

6. A system for automatically encrypting 
and decrypting data packets transmitted from a first host 
computer on a first computer network to a second host 

30 computer on a second computer network, including: 

a first bridge computer coupled to the first 
computer network for intercepting data packets transmitted 
from said first computer network, the first bridge computer 
including a first processor and a first memory storing 

3 5 instructions for executing encryption of data packets 

according to a predetermined encryption/decryption 
mechanism; 

a second bridge computer coupled to the second 
computer network for intercepting data packets transmitted 
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to said second computer network, the second bridge 
computer including a second processor and a second 
memory storing instructions for executing decryption of 
the data packets; 

said first host computer including a third 
processor and a third memory including instructions for 
transmitting a first said data packet from said first host to 
said second host; 

a first table stored in said first memory including 
a correlation of at least one of the first host computer and 
the first network with one of the second host computer and 
the second network, respectively; 

instructions stored in said first memory for 
intercepting said first data packet before departure from 
said first network, determining whether said correlation is 
present in said first table, and if so, then executing 
encryption of said first data packet according to said 
predetermined encryption/decryption mechanism, 
generating a new address header and appending said new 
address header to said first data packet, thereby generating 
a modified first data packet, and transmitting said modified 
first data packet on to the second host computer; 

a second table stored in said second memory 
including a correlation of at least one of the first host 
computer and the first network with one of the second host 
computer and the second network, respectively; 

instructions stored in said second memory for 
intercepting said first data packet upon arrival at said 
second network, determining whether said correlation is 
present in said second table, and if so, then executing 
decryption of said first data packet according to said 
predetermined encryption/decryption mechanism, and 
transmitting the first data packet to the second host 
computer. 

7. The method of claim 6, wherein said 

new address header includes the internetwork broadcast 
addresses of the first and second computer networks. 
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8. The method of claim 7, wherein said 
new address header includes an identifier of the second 
bridge computer. 

9. The method of claim 6, wherein said 
new address header includes the address of the second host 
computer. 

1 0. The method of claim 9, wherein said 
new address header includes an identifier of the second 
bridge computer. 

11. A method for transmitting and 
receiving packets of data via an internetwork from a first 
host computer on a first computer network to a second host 
computer on a second computer network, [the first and 
second computer networks,] each of said first and second 
host computers including a processor and a memory for 
storing instructions for execution by the processor, each 
said memory storing at least on predetermined 
encryption/decryption mechanism and a source/destination 
table identifying a predetermined plurality of sources and 
destinations requiring security for packets transmitted 
between them, the method being carried [carded] out by 
means of the instructions stored in said respective 
memories and including the steps of: 

(1) generating, by the first host computer, a first data 
packet for transmission to the second host computer, a 
portion of the data packet including information 
representing an internetwork address of a source of the 
packet and an internetwork address of a destination of the 
packet; 

(2) in the first host computer, determining whether 
the source and destination of the first data packet are 
among the predetermined plurality of sources and 
destinations identified in said source/destination table for 
which security is required, and if not, proceeding to step 5, 
and if so, proceeding to step 3; 
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(3) encrypting the first data packet in the first host 
computer; 

(4) in the first host computer, generating and 
appending to the first data packet an encapsulation header, 
including: 

(a) key management information identifying the 
predetermined encryption method, and 

(b) a new address header identifying the source and 
destination for the first data packet; 

(5) transmitting the first data packet from the first 
host computer via the internetwork to the second computer 
network; 

(6) in the second host computer, reading the 
encapsulation header, and determining therefrom whether 
the first data packet was encrypted, and if not, ending the 
method, and if so, proceeding to step 7; 

(7) in the second host computer, determining which 
encryption mechanism was used to encrypt the first data 
packet; and 

(8) decrypting the first data packet by the second 
host computer. 

1 2. The method of claim 1 1 , wherein the 
new address header for the modified data packet includes 
internetwork broadcast addresses of the first and second 
computer networks. 

1 3 . The method of claim 1 1 , wherein the 
source/destination table includes data identifying 
internetwork addresses of the first and second host 
computers. 

14. A system for automatically encrypting 
and decrypting data packets transmitted from a first host 
computer on a first computer network and having a first 
host computer on a first computer network and having first 
processor and a first memory, via an internetwork to a 
second host computer on a second computer network and 
having a second host computer on a second computer 
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network and having a second processor and a second 
memory, the system including: 

security data stored in said first and second 
memories indicating that data packets meeting at least one 
predetermined criterion are to be encrypted; 

a predetermined encryption/decryption 
mechanism stored in said first and second memories; 

a decryption key stored in said second memory ; 

instructions stored in said first memory for 
determining whether to encrypt data packets, by 
determining whether said at least one predetermined 
criterion is met by said data packet; 

instructions stored in said first memory for 
executing encryption according to said predetermined 
encryption/decryption mechanism of at least a first said 
data packet, when said at least one predetermined criterion 
is met, for generating a new address header for said first 
data packet and for appending an encapsulation header to 
said first data packet and transmitting said first data packet 
to said second host, said encapsulation header including at 
least said new address header; 

instructions stored in said second memory for 
receiving said first data packet, determining whether it has 
been encrypted by reference to said security data, and if so 
then determining which encryption/decryption mechanism 
was used for encryption, and decrypting said data packet 
by use of said decryption key. 

15. The system of claim 14, wherein: 
said security data comprises correlation data 
stored in each of said first and second memories 
identifying at least one of said first and second memories 
identifying at least one of said first host computer and said 
first network correlated with at least one of said second 
host computer and said second network; 

the system further including instructions stored in 
said first memory for determining whether to encrypt data 
packets by inspecting for a match between source and 
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destination addresses of said data packets with said 
correlation data. 

16. A system for automatically encrypting 
data packets for transmission from a first host computer on 
a first computer network to a second host computer on a 
second computer network, said first host computer 
including a first processor and a first memory including 
instructions for transmitting said data packets from said 
first host to said second host, the system including: 

a bridge computer coupled to the first computer 
network for intercepting at least a first said data packet 
transmitted from said first computer network, said bridge 
computer including a second processor and a second 
memory storing instructions for executing encryption of 
said first data packet according to a predetermined 
encryption/decryption mechanism; 

information stored in said second memory 
correlating at least one of the first host computer and the 
first network with one of the second host computer and the 
second network, respectively; 

instructions stored in said second memory for 
intercepting said first data packet before departure from 
said first network, determining whether said correlation is 
present, and if so, then executing encryption of said first 
data packet according to said predetermined 
encryption/decryption mechanism, generating a new 
address header and appending said new address header to 
said first data packet, thereby generating a modified first 
data packet on to the second host computer. 

1 7. A method for transmitting packets of 
data via an internetwork from a first host computer on a 
first computer network to a second host computer on a 
second computer network, the first computer networks 
including a first bridge computer, each of said first and 
second host computers and said bridge computer further 
including memory storing at least one predetermined 
encryption/decryption mechanism and information 



25 



identifying a predetermined plurality of host computers as 
hosts requiring security for packets transmitted between 
them, the method being carried out according to the 
instructions stored in said respective memories and 
5 including the steps of: 

(1 ) generating, by the first host computer, a first data 
packet for transmission to the second host computer, a 
portion of the data packet including information 
representing an internetwork address of the first host 

1 0 computer and an internetwork address of the second host 

computer. 

(2) in the first bridge computer, intercepting the first 
data packet and determining whether the first and second 
host computers are among the predetermined plurality of 

1 5 host computers for which security is required, and if not, 

proceeding to step 5, and if so, proceeding to step 3; 

(3) encrypting the first data packet in the first bridge 
computer; 

(4) in the first bridge computer, generating and 

20 appending to the first data packet an encapsulation header, 

including: 

(a) key management information identifying the 
predetermined encryption method, and 

(b) a new address header representing the source and 
25 destination for the data packet, 

thereby generating a modified data packet; and 

(5) transmitting the data packet from the first bridge 
computer via the internetwork to the second computer 
network. 

30 

18. A system for automatically decrypting 

data packets transmitted from a first computer to a second 
computer the system comprising: 

a bridge coupled to the second computer for 
35 intercepting a data packet from the first computer, the 

bridge including a processor and a memory that stores 
instructions for decrypting data packets: 

information stored in the memory of the bridge 
correlating the first and second computers: and 
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instructions stored in the memory of the bridge 
for intercepting the data packet, determining whether the 
information stored in the memory of the bridge correlates 
the first and second computers, and if so. decrypting the 
5 data packet to generate a new data packet including a new 

address header, and transmitting the new data packet onto 
the second computer. 

19. The system of claim 1 8. where the data 

10 packet includes an address header and a body, the body 

including the new data packet in encrypted form. 

20. The method of claim 1 8. wherein the 
data packet includes a header storing key management 

15 information identifying an encryption method used to 

encrypt the new data packet. 

2 1 . The method of claim 18. wherein the 
new address header includes information indicating the 

20 first computer is a source of the new data packet and the 

second computer is a destination of the new data packet. 

22. A method for receiving data packets 

transmitted from a first computer to a second computer 

25 through a bridge, the bridge including a processor and a 

memory, the memory storing instructions for decrypting 
data packets and information correlating the first and 
second computers, the method being carried out according 
to instructions in the memory of the bridge and comprising: 

30 intercepting a data packet from the second 

computer to the second computer portion of the data packet 
including information representing an internetwork address 
of the first computer and an internetwork address of the 
second computer: 

35 determining whether the information stored in 

the memory of the bridge correlates the first and second 
computers, and if so. decrypting the data packet to generate 
a new data packet including a new address header: and 
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transmitting the new data packet on to the second 

computer. 

23. The system of claim 22. where the data 

5 packet includes an address header and a body, the body 

including the new data packet in encrypted form. 

24. The method of claim 22. wherein the 

data packet includes a header storing key management 

10 information identifying an encryption method used to 

encrypt the new data packet. 

25. The method of claim 22. wherein the 
new address header includes information indicating the 

15 first computer is a source of the new data packet and the 

second computer is a destination of the new data packet. 

26. A method of encrypting data packets, 
comprising: 

20 receiving a data packet from a source for a 

destination, the data packet including a header section and 
a data section, and the header section storing a source 
identifier and a destination identifier: 

determining whether the data packet should be 

25 encrypted upon reference to at least one of the source and 

destination identifiers: and 

if the data packet should be encrypted, 
encrypting the data packet to produce an encrypted data 
packet. 

30 

27. The method of claim 26. further 
comprising transmitting the encrypted data packet to the 
destination. 

35 28, The method of claim 26. wherein the 

determining whether the data packet should be encrypted 
comprises accessing stored information that indicates by 
presence or absence of the source identifier that data 
packets from the source should be encrypted. 
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29. The method of claim 26. wherein the 
determining whether the data packet should be encrypted 
comprises accessing stored information that indicates by 

5 presence or absence of a correlation between the source 

and destination identifiers that data packets from the source 
for the destination should be encrypted. 

30. The method of claim 26 . wherein the 

10 encrypted data packet includes an encrypted data packet 

header section and an encrypted data packet data section, 
the encrypted data packet data section storing the encrypted 
data packet. 

15 3L The method of claim 30. wherein the 

encrypted data packet header section stores the source and 
destination identifiers. 

32. The method of claim 30. wherein the 

20 source is a host computer in a network and the encrypted 

data packet header section stores an identifier of the 
network. 

33. The method of claim 30. wherein the 
25 destination is a host computer in a network and the 

encrypted data packet header section stores an identifier of 
the network. 

34. The method of claim 26. wherein the 

30 source is a host computer or a network. 

35. The method of claim 26. wherein the 

destination is a host computer or a network. 

35 3£ A computer program product for 

encrypting data packets, comprising: 

computer code that receives a data packet from a 
source for a destination, the data packet including a header 
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section and a data section, and the header section storing a 
source identifier and a destination identifier: 

computer code that determines whether the data 
packet should be encrypted upon reference to at least one 
5 of the source and destination identifiers: 

computer code that encrypts the data packet to 
produce an encrypted data packet if the data packet should 
be encrypted: and 

a computer readable medium that stores the 
10 computer codes. 

37. The computer program product of 
claim 36. wherein the computer readable medium is a 
memory, random-access-memory, read-only-memory, disk 

15 drive, or CD-ROM. 

38. A computer system for encrypting data 

packets, comprising: 

a processor: 

20 a computer readable medium coupled to the 

processor storing a computer program comprising: 

computer code that receives a data packet from a 
source for a destination, the data packet including a header 
section and a data section, and the header section storing a 
25 source identifier and a destination identifier: 

computer code that determines whether the data 
packet should be encrypted upon reference to at least one 
of the source and destination identifiers: and 

computer code that encrypts the data packet to 
30 produce an encrypted data packet if the data packet should 

be encrypted. 

39. The computer program product of 

claim 38. wherein the computer readable medium is a 

35 memory, random-access-memory, read-only-memorv. disk 

drive, or CD-ROM. 



40. A method of decrypting data packets. 

comprising: 
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receiving a data packet from a source for a 
destination, the data packet including a header section and 
a data section, and the header section storing a source 
identifier and a destination identifier: 

determining whether the data packet is encrypted 
upon reference to at least one of the source and destination 
identifiers: and 

if the data packet is encrypted, decrypting the 
data packet to produce a decrypted data packet. 

41. The method of claim 40. further 

comprising transmitting the decrypted data packet to the 
destination. 



15 41 The method of claim 40. wherein the 

determining whether the data packet is encrypted 
comprises accessing stored information that indicates by 
presence or absence of the source identifier that data 
packets from the source are encrypted. 

20 

43. The method of claim 40. wherein the 

determining whether the data packet is encrypted 
comprises accessing stored information that indicates by 
presence or absence of a correlation between the source 

25 and destination identifiers that data packets from the source 

for the destination are encrypted. 

44. The method of claim 40. wherein the 

data section of the data packet includes an encrypted 

30 header section and an encrypted data section for the 

decrypted data packet. 

45. The method of claim 44. wherein the 

encrypted header section stores the source and destination 

35 identifiers. 

46. The method of claim 44. wherein the 

source is a network and the encrypted header section stores 
an identifier of a host computer in the network. 
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47. The method of claim 44. wherein the 

destination is a network and the encrypted header section 
stores an identifier of a host computer in the network. 

5 

48. The method of claim 40. wherein the 
source is a host computer or a network. 

49. The method of claim 40. wherein the 
10 destination is a host computer or a network. 

50. A computer program product for 

decrypting data packets, comprising: 

computer code that receives a data packet from a 
15 source for a destination, the data packet including a header 

section and a data section, and the header section storing a 
source identifier and a destination identifier: 

computer code that determines whether the data 
packet is encrypted upon reference to at least one of the 
20 source and destination identifiers; 

computer code that decrypts the data packet to 
produce a decrypted data packet if the data packet is 
encrypted: and 

a computer readable medium that stores the 
25 computer codes. 

51. The computer program product of 

claim 50. wherein the computer readable medium is a 
memory, random-access-memory, read-only-memory, disk 

30 drive, or CD-ROM. 

52. A computer system for decrypting data 

packets, comprising: 

a processor: 

35 a computer readable medium coupled to the 

processor storing a computer program comprising: 

computer code that receives a data packet from a 
source for a destination, the data packet including a header 
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section and a data section* and the header section storing a 
source identifier and a destination identifier; 

computer code that determines whether the data 
packet is encrypted upon reference to at least one of the 
source and destination identifiers: and 

computer code that decrypts the data packet to 
produce a decrypted data packet if the data packet is 
encrypted. 

53. The computer program product of 
claim 52. wherein the computer readable medium is a 
memory, random-access-memory, read-only-memory, disk 
drive, or CD-ROM. 
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ABSTRACT 



A system for automatically encrypting and decrypting data 
packet sent from a source host to a destination host across a 
public internetwork. A tunnelling bridge is positioned at 
each network* and intercepts all packets transmitted to or 
from its associated network. The tunnelling bridge includes- 
tables indicated pairs of hosts or pairs of networks between 
which packets should be encrypted. When a packet is 
transmitted from a first host, the tunnelling bridge of that 
host's network intercepts the packet, and determines from its 
header information whether packets from that host that are 
directed to the specified destination host should be 
encrypted; or, alternatively, whether packets from the source 
host's network that are directed to the destination host's 
network should be encrypted. If so, the packet is encrypted, 
and transmitted to the destination network along with an 
encapsulation header indicating source and destination 
information: either source and destination host addresses, or 
the broadcast addresses of the source and destination net- 
works (in the latter case, concealing by encryption the hosts' 
respective addresses). An identifier of the source network's 
tunnelling bridge may also be included in the encapsulation 
header. At the destination network, the associated tunnelling 
bridge intercepts the packet, inspects the encapsulation 
header, from an internal table determines whether the packet 
was encrypted, and from either the source (host or network) 
address or the tunnelling bridge identifier determines 
whether and how the packet was encrypted. If the packet 
was encrypted, it is now decrypted using a key stored in the 
destination tunnelling bridged memory, and is sent on to the 
destination host. The tunnelling bridge identifier is used 
particularly in an embodiment where a given network has 
more than one tunnelling bridge, and hence multiple pos- 
sible encryption/decryption schemes and keys. In an alter- 
native embodiment, the automatic encryption and decryp- 
tion may be carried out by the source and destination hosts 
themselves, without the use of additional tunnelling bridges, 
in which case the encapsulation header includes the source 
and destination host addresses. 
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No. 37,260 and Elise R. Heilbrunn, Reg. No. P42,649 all of the law firm of Beyer & Weaver, 
LLP; and Kenneth Olsen (Reg. No. 26,493); Matthew C. Rainey (Reg. No. 32,291); Erwin J. 
Basinski (Reg. No. 34,773); Timothy J. Crean (Reg. No. 37,116); Robert S. Hauser (Reg. 
No. 37,847); Patrick J.S. Inouye (Reg. No. 40,297) Joseph T. FitzGerald (Reg. No. 33,881); 
Alexander E. Silverman (Reg. No. 37,940) of SUN MICROSYSTEMS, INC. with full power 
of substitution and revocation, to prosecute this application and to transact all business in the 
Patent and Trademark Office connected therewith. 

Pursuant to 37 C.F.R. §3.71, the assignee hereby states that prosecution of the 
above-referenced patent application is to be conducted to the exclusion of the inventor(s). 



Please send all correspondence for this application as follows: 



Michael J. Ritter 

BEYER & WEAVER, LLP 
P.O. Box 61059 
Palo Alto, CA 94306 



Please direct any calls to the same at (650) 493-2100. 



Assignee of Interest: 



Sun Microsystems, Inc. 
901 San^Antonio Road 
Pa>rltfto7CA 94303^, 





Name: Kenneth Olsen 

Reg. No.: 26,493 

Title: Vice President, Intellectual Property 
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PATENT 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

In re the application of ) 

AZIZ et al. ) 

Reissue of U.S. Patent No.: 5,548,646 ) 

Issued: August 20, 1996 ) 

Assignee: Sun Microsystems, Inc. ) 

For: SYSTEM FOR SIGNATURELESS ) 
TRANSMISSION AND RECEPTION OF ) 
DATA PACKETS BETWEEN COMPUTER ) 
NETWORKS ) 



Establishing Right Of Assignee To Take Action 
under 37 C.F.R. 3.73(b) and 
Assent Of Assignee 
under 37 C.F.R. 1.172(a) 

Commissioner of Patents and Trademarks 
Washington, D.C. 2023 1 

Sir: 

1 . The assignee of the entire right, title and interest hereby seeks to take action in 
the Patent and Trademark Office in this matter. 

IDENTIFICATION OF ASSIGNEE 

2. Sun Microsystems. Inc. 

(Name of Assignee) 

A Delaware Corporation 

(Type of Assignee, e.g. corporation, partnership, university, gov't agency, etc.) 

PERSON AUTHORIZED TO SIGN 

3. Kenneth Olsen 

(Type name of person authorized to sign on behalf of assignee) 

Vice President. Intellectual Property 

(Title of person authorized to sign) 

I, the person signing below, aver that I am empowered to sign this statement on behalf 
of the assignee. 



Attorney Docket No. SUN1P342R 1 



BASIS OF ASSIGNEE'S INTEREST 

Ownership by the assignee is established by two assignment documents forming a 
chain of title from the inventors to the current assignee as shown below: 

L From: Ashar Aziz 

(Name of inventor(s) or assignee) 

To: Sun Microsystems. Inc. 

Dated: October 14, 1994 

2. From: Martin Patterson 

(Name of inventor(s) or assignee) 

To: Sun Microsystems, Inc. 

Dated: October 13, 1995 

3 . From Geoffrey Mulligan 

(Name of inventor(s) or assignee) 

To: Sun Microsystems, Inc. 

Dated: October 14, 1995 

4. From: Glenn Scott 

(Name of inventor(s) or assignee) 

To: Sun Microsystems. Inc. 

Dated: October 14, 1995 

Copies of the assignments in the chain of title are attached. 

DECLARATIONS 

I, the undersigned, have reviewed all of the evidentiary documents for the above- 
identified application, and, to the best of my knowledge and belief, title is in the assignee 
seeking to take this action. 

I, hereby declare that all statements made herein of my own knowledge are true, and 
that all statements made on information and belief are believed to be true; and further, that these 
statements are made with the knowledge that willful false statements, and the like so made, are 
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punishable by fine or imprisonment, or both, under Section 1001, Title 8 of the United States 
Code, and that such willful false statements may jeopardize the validity of the application or 
any patent issuing thereon. 



ASSENT OF ASSIGNEE 

Sun Microsystems, Inc. of Delaware, the sole owner of U.S. Patent No. 5,548,646 by 
virtue of the assignments copies of which are enclosed herewith, hereby assents to the filing of 
an application for reissue of said patent and to the issuance of a reissue paJsftHh^refor. 



Date: 



late* 




Name: Kenneth Olsen 
Title: Vice President, 

Intellectual Property 
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